During the project, the business case is verified at predefined points in time to ensure that the eventual results remain valid for the client. TMap supports the justification of IT, translating it to the activity of testing. TMap assumes that a project approach based on a business case complies with the following characteristics:

• The approach focuses on achieving a predefined result.
• The total project to achieve this result is realised within the available (lead) time.
• The project to achieve this result is realised at a cost in balance with the benefits the organisation hopes to achieve.
• The risks during commissioning are known and as small as possible. All of this within the framework set by the abovementioned characteristics.

The four IT governance aspects described above can be found in these characteristics. For the successful execution of a project, it is important that the test process is aligned with the business case. The relationship between the business case and the test process is made via the business driven test management approach. In other words, with this approach, the business case characteristics can be ‘translated’ to the test process.

Characteristics of a business driven test management approach

Often test plans and reports fail to appeal to the client. The reason being that in the past the tester virtually always made decisions from an IT perspective. The test process was internally oriented and filled with test and IT jargon. This made it difficult to communicate with a non-IT client, such as a user department, even though this is extremely important.

TMap devotes explicit attention to communication due to the business driven test management approach.1 BDTM starts from the principle that the selected test approach must enable the client to control the test process and (help) determine the test approach. This gives the testing an economic character. The required information to make this possible is delivered from the test process.

BDTM has the following specific properties:

• The total test effort is related to the risks of the system to be tested for the organisation. The deployment of people, resources and budget thereby focuses on those parts of the system that are most important to the organisation. In TMap, the test strategy in combination with the estimated effort is the instrument to divide the test effort over system parts. This provides insight into the extent to which risks are covered, or not.
• The estimated effort and planning for the test process are related to the defined test strategy. If changes are implemented that have an impact on the thoroughness of testing for the various system parts or systems, this is translated immediately to a change in the estimate and/or planning. The organisation thus is ensured of an adequate view of the required budget, lead time and relationship with the test strategy at all times.
• At various moments in the testing programme, the client is involved in making choices. The advantage is that the test process matches the wishes and requirements – and therefore the expectations – of the organisation as adequately as possible. Moreover, BDTM provides handholds to visualise the consequences of future and past choices explicitly.

The steps in the business driven test management approach

To understand the BDTM approach, it is important to keep an eye on the final objective. Which is to provide a quality assessment and risk recommendation about the system. Since not everything can ever be tested, a correct assessment can only be realised by dividing the test effort, in terms of time and money, as adequately as possible over parts and characteristics of the system to be tested. The steps of BDTM focus on this (see figure 2):

1. Formulating the assignment and gathering test goals - In consultation with the client, the test manager formulates the assignment, taking account of the four BDTM aspects: result, risk, time and cost. The test manager gathers the test objectives to determine the desired results of testing for the client. A test goal is a goal for testing relevant to the client and other acceptants, often formulated in terms of IT-supported business processes, realised user requirements or use cases, critical success factors, change proposals or defi ned risks (i.e., the risks to be covered).

2. Determining the risk class for each combination of characteristic and object part - When multiple test levels are involved, it is determined in a plan which test levels must be set up (master test plan). It is often already determined on the basis of a product risk analysis2 what must be tested (object parts) and what must be investigated (characteristics). If only one test level is involved, or if no or an overall product risk analysis was performed at the master test plan level, a (possibly supplementary) product risk analysis is performed within the relevant test level.

The eventual result (whether it is arrived at immediately or after one or more supplementary analyses) is a risk table defining a risk class related to the test goals and the relevant characteristic per object part (“Master test plan risk table”). A table then provides a guideline for the relative depth of testing per combination of characteristic/object part and test level (“Master test plan strategy table”).

Now an iterative process emerges:

3. Determining whether a combination of characteristic and object part must be tested thoroughly or lightly - To determine the thoroughness of testing, the risk class per object part determined in the previous step is used as a starting point. Initially, the following applies: the greater the risk, the more thorough the required testing. The result is recorded in a strategy table per test level (“Test plan strategy table”).

4. An overall estimate is then made for the test and a planning set up - This is communicated with the client and other stakeholders and, depending on their views, adjusted as necessary. In this case, steps 3 and 4 are executed once again. This emphatic gives the client control of the test process, enabling him to manage based on the balance between result and risk on the one hand and time and cost on the other.

End of iteration.

5. Allocating test techniques to the combinations of characteristic and object part - When the client and stakeholders agree on the estimate and the planning, the test manager completes a “Test design table”. In here, the decisions concerning thorough and less thorough testing are translated to concrete statements about the targeted coverage. He then allocates test techniques to the combinations of characteristic and object part. The available test basis, among other things, is taken into account. These techniques are used to design and execute the test cases (and/or checklists) at a later stage. This is where the primary test process starts.

6. Throughout the test process, the test manager provides the client and other stakeholders with adequate insight into and control options over:

• the progress of the test process
• the quality and risks of the test object
• the quality of the test process.

Figure 1: BDTM steps

In summary, the advantages of the BDTM approach are:

• The client having control over the process.
• The test manager communicates and reports in the terminology of the client with information that is useful in the client’s context. E.g. by reporting in terms of test goals (such as business processes) instead of object parts and characteristics.
• At the master test plan level, detailing can be as intensive as required or possible. This may enable expending less effort on performing a product risk analysis or creating a test strategy for the separate test levels, or even to skip these steps (explanation of master test plan in subsequent section).